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(57) Abstract: Techniques for configuring 
network security include obtaining non-packet 
flow information, evaluating a policy rule 
based on the obtained information, and 
proposing a security arrangement based on the 
evaluation. The non-packet flow information 
can include, for example, authentication 
information obtained during an Internet Key 
Exchange protocol session or information 
obtained from a layered service provider. 
Therefore, policies such as Internet Protocol 
security (IPsec) policies can be defined and 
implemented so that they more accurately 
reflect the network's security requirements. 
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ESTABLISHING NETWORK SECURITY USING INTERNET PROTOCOL SECURITY 

POLICIES 

BACKGROUND 

5 The invention relates to establishing network security 

using Internet Protocol security (IPsec) policies. 

IPsec is a network-layer security framework for 
implementing security for communications on networks using the 
Internet Protocol (IP) through the use of cryptographic key 

10 management procedures and protocols. Communications between 
two endpoints of an IP traffic flow are made secure by the 
IPsec protocol on an individual IP packet basis. IPsec 
entities at connection endpoints have access to and 
participate in operations that make a common connection 

15 secure. 

IPsec establishes and uses a security association to 

identify a secure channel between two endpoints. A security 

association is a unidirectional session between two 

termination endpoints. One endpoint sends IP packets, and a 

20 second endpoint receives the IP packets. A minimum of two 

security associations is required for secure, bi-directional 

communications. The two endpoints can use the Internet Key 

Exchange (IKE) protocol to negotiate mutually acceptable 
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encryption algorithms, associated parameters and secret keys 
to protect network traffic. The IKE protocol supports various 
authentication mechanisms including pre-shared keys, X.509 
public key certificates and Kerberos tickets. 
5 Policy-based network management (PMNM) often is used to 

determine who can use the resources and services associated 
with the network, under what conditions they are used, and 
when. Security policies, for example, define a set of rules 
governing encryption and access control decisions. The 
10 policies can be expressed as a set of rules each of which 

includes a predicate and an action. In other words, a rule 
can be expressed as "if <condition> is satisfied, then do 
<action> . " 

An exemplary action at the IPsec layer may propose a 
15 specific set of security algorithms. Current IPsec protocol 

implementations typically use packet flow information, such as 
IP addresses, protocol and ports, to evaluate the policy 
decisions . 



20 BRIEF DESCRIPTION OF THE DRAWINGS 

FIG. 1 illustrates a system including IPsec-enabled 
devices . 
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FIG. 2 is a flow chart of a method of establishing a 
security association . 

FIG. 3 illustrates workgroups in a policy-based network 
management infrastructure . 
5 FIG. 4 shows a set of rules associated with the 

workgroups in FIG. 3. 



10 DETAILED DESCRIPTION 

FIG. 1 illustrates a system 10 with IPsec-enabled devices 
12, 14 that can communicate over a network 16. Each of the 
devices 12 , 14 includes a layered protocol stack that has an 
IPsec component 18 and an IKE component 20. The device 12 

15 also includes a database 22 that stores rules corresponding to 
security policies for implementing the security requirements 
of the device. A policy agent 24 retrieves the rules stored 
by the database 22 and interprets and evaluates the rules. As 
described in greater detail below, the policy agent 24 can 

20 exchange information with the IKE layer component 20, as well 
as various information providers, to augment the network flow 
information that drives the policy decisions. 
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As indicated by FIG . 2, when the device 12 attempts to 
send or receive IP data to the other device 14, the IPsec 
layer 18 in the device 12 attempts to find 40 a security 
association, in other words, a set of encryption, 
5 authentication and/or compression algorithms and keys, to 
protect the traffic. If a security association is not yet 
established, the IPsec layer 18 initiates 42 a process to 
establish one or more security associations to be used for 
future traffic that matches the same IP address, port and 

10 protocol. The IKE protocol is used to negotiate the keys and 
algorithms of the security associations. During a first IKE 
phase, the devices 12, 14 exchange and authenticate identity 
information and establish a secure channel protected by an IKE 
security association to use for a second IKE phase. During 

15 the second phase, the devices 12, 14 negotiate security 

associations for the IP traffic that is to be protected by 
IPsec . 

As noted, during the first IKE phase, the IKE layer 20 in 
the device 12 obtains 44 authenticated identity information 28 
20 from the device 14. The identity information can include, for 
example, a digital certificate, a us ername -pas sword pair or a 
Kerberos ticket. The identity information can identify a peer 
device and may be associated with a particular device such as 
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the device 14 or a group of devices. Alternatively, the 
identity information may be associated with a particular 
individual or group of individuals. For example, a hospital 
may have doctors , nurses and administrative staff organized in 
5 workgroups each of which may have specific access privileges 
and security requirements. The identity information can be 
associated with a particular group of the hospital staff. 
FIG. 3 illustrates three exemplary workgroups in a policy- 
based network management infrastructure. Each client (machine 

10 or user) in a workgroup has an ordered list of policy objects, 
and each policy object includes a set of rules to apply to 
traffic flows between two endpoint lists. For example, the 
source list can identify machines in the source workgroup, 
whereas the destination list can identify machines in the 

15 destination workgroup. Smart cards, which can store 
certificates in a secure manner, can enable tying the 
certificate to one or more users rather than to the machines. 
The certificate would then identify the user or the machine as 
being a member of a particular workgroup. The non-packet flow 

20 information can include biometric data that identifies the 
user as well. 

Once the IKE layer 20 in the device 12 obtains the 
authenticated identity information, the identity information 
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is obtained 46 by the policy agent 24. The IKE layer 20 can 
include an application programming interface (API) to allow 
the policy agent 24 to extract the authenticated identity 
information. Alternatively, the IKE layer 20 can send the 
5 authenticated identity information to the policy agent. The 
policy agent 24 can use the identity information to interpret 
and evaluate 48 policies that are stored in the database 22 
and that include a condition referring to the IKE layer 
identity information. For example, a particular policy may 

10 indicate that if the identity information includes a 

particular digital certificate, then traffic must be sent in 
the clear, denied or secured using a set of security 
parameters. Exemplary forms for the rules associated with one 
of the workgroups of FIG. 3 are shown in FIG. 4. In general, 

15 the sets of rules should be symmetrical and synchronized 
across all the workgroups. 

The policy agent 24 also can pass 50 the authenticated 
identity information to a flow context module 30 which may 
reside within the policy agent or which may be separate from 

20 the policy agent. The module 30, which can be implemented, 
for example, in random access memory (RAM) , serves as a 
repository for information that can flow to the policy agent 
24. The module 30 also can obtain additional information from 
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other sources, such as a layered service provider 26 or other 
network interceptor. The information obtained from the 
layered service provider 26 then can be passed 52 to the 
policy agent 24 and used to evaluate 54 IPsec policies stored 
5 in the database 22. That allows IPsec policies to be based on 
a specific application, as well as the identity of the logged- 
in user and/or peer identities. For example, in some 
implementations, the layered service provider 26 would 
determine that a certain application is responsible for a 

10 specific connection request and would advertise the 

application's name as "Application = XYZ." The form in which 
the extended information is represented can be similar to the 
form in which the identity information is represented. 
Therefore, the same syntax can be used when incorporating the 

15 IKE layer identity information or the information from the 

layered service provider 26 into predicates in the policies. 
Some sources of context information, such as user-loadable 
programs and dynamic link libraries (DLLs) may require 
authentication by the policy evaluator to certify the 

20 reliability of the information they provide. Such 

authentication can be provided using bilateral software 
authentication technology. Preferably, information obtained 
from other sources such as the layered service provider 26 is 
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used to augment, but not override, values in the authenticated 
identity information obtained from the IKE layer 20. 

The non-packet flow information that is received, for 
example, through the flow context module 30 can be viewed as a 
5 set of attributes each of which has an associated value. The 
packet flow itself is identified by several parameters, 
including a source address, a source port, a destination 
address, a destination port and a protocol. Those parameters 
can be added to the flow context information so that as data 
10 packets are processed, there is sufficient information to look 
up the corresponding flow context information to evaluate the 
policy rules. Such a technique can facilitate integration of 
the non-packet flow information with the packet flow 
information . 

15 Once the policy agent 24 evaluates the policies in the 

database 22, the policy agent 24 passes 56 a prioritized list 
of one or more protection suite proposals to the IKE layer 20 
in the device 12. The IKE layer 20 in the device 12 then 
passes 58 the prioritized list of protection suite proposals 

20 to the IKE layer 20 in the device 14. The device 14 examines 
60 the proposed protection suites and attempts to find an 
acceptable protection suite on the list. Once the devices 12, 
14 agree on an acceptable security arrangement, the IPsec 
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layer 18 in each device is configured 62 to use the agreed- 
upon suite of security arrangements during the second phase of 
the IKE protocol. 

As mentioned previously, various types of non-packet flow 
5 information can be incorporated into the predicates of IPsec 
policies. Specific examples include user identity data, 
application identifiers, and application modes. User identity 
data, for example, can be obtained from smart cards or 
biometric devices. Such identity data also can include a 

10 password entered, for example, when the user logs on to the 
system. The digital certificate information can include 
fields such as the certificate serial number, the subject's 
name, the subject's public key, the subject's alternate names, 
key identifiers and the expiration date of the certificate. 

15 The information in any of those fields can be incorporated 
into the predicates of one or more policy rules, and the 
received digital certificate can be used to evaluate the 
rules . 

If the IKE layer 20 in the first device is unable to 
20 authenticate identity information from the second device 14 
during the IKE session, then the IKE layer itself may act as 
an information provider. For example, the IKE layer 20 can 
indicate to the policy agent 24 that authenticated identity 



WO 02/01827 



PCT/US01/18676 



information is unavailable for the particular connection 
request. The policy agent 2 4 would then use that fact to 
evaluate one or more default policies in the database 22. 

In one particular scenario, an application identifier can 
5 be used to evaluate IPsec policies as follows. An application 
(not shown) loads a layered service provider DLL automatically 
as it loads Winsock 2 to perform network communications. The 
layered service provider hashes the application binary 
executable file and looks it up in a database of known 

10 applications. The layered service provider then signs the 
application identifier and passes the signed value to the 
module 30 along with the packet flow information (i.e., 
address, port and protocol) . The module 30 creates a record 
for the data flow, checks the validity of the application 

15 identifier, and adds the identifier to the flow context. As 
the policy agent 24 evaluates the policies in the database 22, 
rules that specify an application identifier are evaluated 
against the application identifier in the context record. 
An application also can declare and sign the mode in 

20 which it is running. Examples include a browser running in 

Secure Socket Layer (SSL), an electronic mail (e-mail) 

application sending or receiving messages, and a browser 

accessing web sites on a particular domain. As the policy 

- 10- 



WO 02/01827 



PCT/US01/18676 



agent 24 evaluates the policies in the database 22, rules that 
specify an application mode are evaluated against the actual 
mode in which the application is running. 

Although the foregoing description relates to the use of 
5 non-packet flow information to evaluate policies and negotiate 
a security association during the first phase of an IKE 
session, the non-packet flow information also can be used 
during subsequent phases of an IKE session to evaluate 
policies and negotiate security associations. 

10 Various features of the system can be implemented in 

hardware, software, or a combination of hardware and software. 
For example, some aspects of the system can be implemented in 
computer programs executing on programmable computers. Each 
program can be implemented in a high level procedural or 

15 object-oriented programming language to communicate with a 

computer system. Furthermore, each such computer program can 
be stored on a storage medium, such as read-only-memory (ROM) 
readable by a general or special purpose programmable 
computer, for configuring and operating the computer when the 

20 storage medium is read by the computer to perform the 
functions described above. 

Other implementations are within the scope of the 
following claims. 
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What is claimed is: 

1. A method of establishing network security comprising: 
obtaining non-packet flow information; 

evaluating a policy rule based on the obtained 
5 information; and 

proposing a security arrangement based on the evaluation. 

2. The method of claim 1 wherein the non-packet flow 
information includes peer identity information. 

10 

3. The method of claim 1 wherein the non-packet flow 
information includes user identity information. 

4. The method of claim 3 including obtaining the user 
15 identity information from a smart card. 

5. The method of claim 3 wherein the non-packet flow 
information includes biometric data. 

20 6. The method of claim 1 wherein the non-packet information 
includes authenticated identity information obtained during an 
Internet Key Exchange protocol session. 
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7. The method of claim 6 wherein the identity information is 
included in a digital certificate. 

8. The method of claim 6 wherein the identity information is 
5 included in a Kerberos ticket. 

9. The method of claim 1 including obtaining the non-packet 
flow information from a network interceptor. 

10 10. The method of claim 1 wherein the non-packet flow 
information includes an application identifier. 

11. The method of claim 1 wherein the non-packet flow 
information includes an identification of a mode in which an 

15 application is executing. 

12. The method of claim 1 including configuring an Internet 
Protocol security layer according to the proposed security 
arrangement . 

20 

13. A security-enabled device comprising: 

a protocol stack; 

a database of policy rules; and 

- 13 - 



WO 02/01827 



PCT/US01/18676 



a policy agent configured to obtain non-packet flow 
information received from a second device, evaluate a policy 
rule stored in the database based on the obtained information, 
and propose a security arrangement based on the evaluation for 
future communications with the second device. 

14. The device of claim 13 wherein the policy agent is 
configured to receive non-packet flow information from a 
network interceptor and to evaluate a policy rule stored in 
the database based on the received information, wherein the 
proposed security arrangement depends on the received non- 
packet flow information. 

15. The device of claim 13 wherein the policy agent is 
arranged to configure an Internet Protocol security component 
according to the proposed security arrangement if, during an 
Internet Key Exchange session, the second device agrees to use 
the proposed security arrangement. 

16. An article comprising a computer-readable medium that 

stores computer-executable instructions for causing a computer 

system to: 

obtain non-packet flow information; 
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evaluate a policy rule based on the obtained information; 

and 

propose a security arrangement based on the evaluation. 

5 17. The article of claim 16 wherein the non-packet flow 
information includes peer identity information. 

18. The article of claim 16 wherein the non-packet flow 
information includes user identity information. 

10 

19. The article of claim 16 wherein the non-packet 
information includes authenticated identity information 
obtained during an Internet Key Exchange protocol session. 

15 20. The article of claim 19 wherein the identity information 

is included in a digital certificate. 

21. The article of claim 19 wherein the identity information 
is included in a Kerberos ticket. 

20 

22. The article of claim 16 wherein the non-packet flow 
information is obtained from a layered service provider. 
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23. The article of claim 16 wherein the non-packet flow 
information includes an application identifier. 

24. The article of claim 16 wherein the non-packet flow 
5 information includes biometric data. 

25. The article of claim 16 wherein the non-packet flow 
information includes an identification of a mode in which an 
application is executing. 

10 

26. The article of claim 16 including instructions to 
configure an Internet Protocol security layer according to the 
proposed security arrangement if, during an Internet Key 
Exchange session, a second device agrees to use the proposed 

15 security arrangement. 

27. A communications system comprising: 

first and second Internet Protocol security-enabled 
devices, wherein both devices include respective protocol 
20 stacks having an Internet Key Exchange component and an 
Internet Protocol security component; and 

a network over which the first and second devices can 
communicate, 

- 16- 



WO 02/01827 



PCT/US01/18676 



wherein the first device further includes a database of 
policy rules and a policy agent, wherein the policy agent is 
configured to obtain non-packet flow information received by 
the first device's Internet Key Exchange component from the 
5 second device's Internet Key Exchange component, to evaluate a 
policy rule stored in the database based on the obtained 
information, and to propose an Internet Protocol security 
arrangement based on the evaluation for future communica-tions 
in an Internet Key Exchange session with the second device. 

10 

28. The system of claim 27 wherein the policy agent is 
configured to receive non-packet flow information from a 
network interceptor and to evaluate a policy rule stored in 
the database based on the received information, wherein the 

15 proposed security arrangement depends on the received non- 
packet flow information. 

29. The system of claim 27 wherein the policy agent is 
arranged to configure the first device's Internet Protocol 

20 security component according to the proposed security 

arrangement if, during an Internet Key Exchange session, the 
second device agrees to use the proposed security arrangement. 
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IPSEC LAYER 18 IN THE DEVICE 12 ATTEMPTS TO FIND A 
SECURITY ASSOCIATION 



IPSEC LAYER 18 INITIATES PROCESS TO ESTABLISH ONE OR MORE 

SECURITY ASSOCIATIONS 



IKE LAYER 20 IN THE DEVICE 12 OBTAINS AUTHENTICATED IDENTITY 
INFORMATION 28 FROM THE DEVICE 14 



THE AUTHENTICATED IDENTITY INFORMATION IS OBTAINED BY 

THE POLICY AGENT 24 



THE POLICY AGENT 24 USES THE IDENTITY INFORMATION TO 
INTERPRET AND EVALUATE POUCIES STORED IN THE DATABASE 22 



THE POLICY AGENT 24 PASSES 50 THE AUTHENTICATED IDENTITY 
INFORMATION TO A FLOW CONTEXT MODULE 30 



INFORMATION OBTAINED FROM OTHER SOURCES (E.G., A LAYERED 
SERVICE PROVIDER 26 OR OTHER NETWORK INTERCEPTOR) IS 
PASSED TO THE POLICY AGENT 24 



INFORMATION FROM THE OTHER SOURCES (E.G., THE LAYERED 
SERVICE PROVIDER OR OTHER NETWORK INTERCEPTOR) IS USED TO 
EVALUATE POLICIES STORED IN THE DATABASE 22 



THE POLICY AGENT 24 PASSES A PRIORITIZED LIST OF ONE OR MORE 
PROTECTION SUITES TO THE IKE LAYER 20 IN THE DEVICE 12 



IKE LAYER 20 IN THE DEVICE 12 PASSES THE PRIORITIZED LIST OF 
PROTECTION SUITES TO THE IKE LAYER 20 IN THE DEVICE 14 



THE DEVICE 14 EXAMINES THE PROPOSED PROTECTION SUITES AND 
ATTEMPTS TO FIND AN ACCEPTABLE PROTECTION SUITE ON THE LIST 



IPSEC LAYER 18 IN EACH DEVICE 12, 14 IS CONFIGURED TO USE THE 
AGREED-UPON SUITE OF SECURITY ARRANGEMENTS 

FIG. 2 
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FIG. 3 



Policy Object 1 

From Workgroup 1 (Endpoint List S n ... S 1n )to Workgroup 

1 (Endpoint List S 1 1 .. . S 1n ) 
Apply ruleset X11 

Policy Object 2 

From Workgroup 1 (Endpoint Lists 77 ... S 1n ) to Workgroup 

2 (Endpoint List S 2 / . . . S 2n ) 
Apply ruleset XI 2 

Policy Object 3 

From Workgroup 1 (Endpoint List S 77 ... S 1n ) to Workgroup 

3 (Endpoint List S 31 ... S 3n ) 
Apply ruleset X1 3 
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